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REMARKS 

The following remarks are responsive to the Final Office Action dated July 9, 2010. 

Claim Rejection Under 35 U.S.C. $ 103 

In the Final Office Action, the Examiner rejected claims 1, 8, 11-13, 15, 18-22, 26, 27, 
30, 33, 39, and 40 under 35 U.S.C. 103(a) as being unpatentable over Pesce et al. (U.S. Patent 
No. 7,328,278), Sankaran et al. (U.S. Patent Publication No. 2003/0231587) and Gaddis et al. 
(U.S. Patent No. 7,554,930). Applicant respectfully traverses the rejection. The applied 
references fail to disclose or suggest the techniques defined by Applicant's claims, and provide 
no teaching that would have suggested the desirability of modification to arrive at the claimed 
techniques. 

Response to Examiner 's Characterization of Applicant 's Arguments 
Prior to addressing each individual claim, Applicant directs the Office to remarks set 
forth by the Examiner in the "Response to Arguments" section of the present Office Action. In 
this section, the present Office Action mischaracterizes many argument set forth in the record by 
the Applicant and, in doing so, effectively reads out elements expressly required by the claims. 

First, in the previous Amendment filed May 6, 2010, Applicant point out that the 
combination of Pesce in view of Sankaran and Gaddis do not teach or suggest, when the number 
of routes exported from the exterior routing protocol process to the interior routing protocol 
process exceeds an export limit, operating the network device in an overload condition in which 
the network device . . . (ii) rebuilds the routing information of the interior routing protocol by 
updating the routing information of the interior routing protocol to associate interior routes with 
a maximum metric that defines a maximum distance from the network device to neighboring 
network devices, as required by claim 1 1 . Applicant noted in particular that this feature of claim 
1 1 requires rebuilding the routing information of the interior routing protocol to associate interior 
routes with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices. None of Pesce, Sankaran or Gaddis, or even the combination 
thereof, provide any suggestion of rebuilding the routing information of the interior routing 
protocol such that each interior routes has a particular metric. Applicant even noted that, while 
Pesce describes a metric value, none of the references teach rebuilding routes to set a maximum 
metric value for each route, as recited by claim 1 1 . In particular, this Pesce metric value is 
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associated with route mapping information that is distinctly different from routing information of 
the interior routing protocol and, moreover, this use of route mapping information by Pesce in no 
way suggests the features required by claim 1 1 . 

In a section of the current Final Office Action entitled "Response to Argument" 
beginning on page 3, the Examiner appears to improperly read out these pertinent aspects of this 
feature of claim 1 1 when applying the prior art and responding to Applicant's arguments. To 
illustrate, the Examiner summarized the above argument in this section as ". . . applicant argues 
that cited references do not teach utilizing a metric." This is not the case and, in fact, Applicant 
acknowledged in the previously filed Amendment that Pesce teaches to a metric value, but the 
teachings related to Pesce's metric value, even in view of the other references, suffer from the 
deficiencies noted above. Thus, rather than address these deficiencies noted above with respect 
to Pesce, the Examiner then indicates in the "Response to Arguments" section of the current 
Final Office Action that "Both Gaddis and Sankaran teach utilizing a path metric such as 
ASPath (Gaddis column 6, lines 44-58, Sankaran paragraph 32), in addition to the metric 
utilized by Pesce to determine table information and which routes to maintain within the table." 
According to the cited portion of Gaddis, the AS_Path is characterized as an attribute that "keeps 
track of the various ASs [sic] that a particular route goes through." This portion of Gaddis 
indicates that this AS_Path attribute is stored as a list of ASes through which any given route 
passes, where ASes refers to autonomous systems (which usually correlate one-to-one with 
service provider networks). This AS_Path attribute therefore stores a list of ASes and is not a 
maximum metric that defines a maximum distance from the network device to neighboring 
network devices as required by Applicant's claim 1 1 . Moreover, the cited portion of Sankaran 
differentiates between route metrics and this AS Path attribute when specifically stating that "a 
route may include a destination IP address, a next hop IP address, age information, preference 
information, metric information, any associated labels, an AS path, state information, or any 
combination thereof." (Emphasis added) In other words, the AS Path referred to by both Gaddis 
and Sankaran is not even considered a metric even by the references themselves, contrary to the 
Examiner's assertions otherwise. Moreover, regardless of whether the ASPath can be construed 
as a metric or not, or even taking Sankaran's explicit mention of metric information, not one of 
the applied references, whether considered alone or in combination, teach or suggest , when the 
number of routes exported from the exterior routing protocol process to the interior routing 
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protocol process exceeds an export limit, operating the network device in an overload condition 
in which the network device . . . (ii) rebuilds the routing information of the interior routing 
protocol by updating the routing information of the interior routing protocol to associate interior 
routes with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices, as required by claim 11. 

To summarize, contrary to the Examiner's characterization of Applicant's arguments, 
Applicant has never argued that the general notion of a metric does not exist in the prior art and 
acknowledged the particular metric value as taught by Pesce. Instead, Applicant pointed out that 
this Pesce 's metric value does not teach or suggest rebuilding the routing information of the 
interior routing protocol by updating the routing information of the interior routing protocol to 
associate interior routes with a maximum metric that defines a maximum distance from the 
network device to neighboring network devices recited by claim 1 1 . The Pesce metric value is 
associated with route mapping information that is distinctly different from routing information of 
the interior routing protocol and, moreover, this Pesce metric value is not even so much as 
updated in the manner required by claim 1 1 . Consequently, the Examiner has read out pertinent 
aspects of this feature of claim 11, which is impermissible. Applicant respectfully requests that 
the Examiner address the actual language, and not some generalized form of this language, that 
sets out this feature of claim 1 1 . 

Second, as another illustration of improperly reading out pertinent limitations of another 
feature of claim 11, consider Applicant's argument in the previous Amendment where Applicant 
argued that the applied references do not teach or suggest when the number of routes exported 
from the exterior routing protocol process to the interior routing protocol process exceeds an 
export limit, operating the network device in an overload condition in which the network device: 
(i) updates routing information of the interior routing protocol to clear the routes previously 
exported from the exterior routing protocol, as required by claim 1 1 . With respect to this feature 
of claim 1 1 , the Examiner turned to Sankaran in both the previous and the current Office Action, 
explicitly acknowledging that "Pesce does not expressly teach a client setting an export limit for 
the device." Applicant rebutted this portion of the rejection, correctly noting that Sankaran 
teaches to "a threshold that triggers different discard algorithms" and that, in this sense, Sankaran 
"provides for 'threshold specific discard algorithms' that are applied once certain thresholds are 
reached." (Bottom of page 11, Applicant's Amendment filed May 6, 2010) While 
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acknowledging these teachings, Applicant concluded that Sankaran fails to teach or suggest the 
features of claim 1 as a whole because Sankaran culls the routing table to remove all redundant 
routes (i.e., duplicate routes), which is substantially different from updating route information of 
the interior routing protocol to clear all of the routes that were previously exported from the 
exterior routing protocol such that only interior routes remain, as required by Applicant's claim 
1 1 . That is, claim 1 1 requires that certain routes are cleared, i.e., routes that were previously 
exported from the exterior routing protocol such that only interior routes remain. Applicant 
argued that Sankaran' s removal of redundant routes does not teach or suggest these features as a 
whole. 

The Examiner, in the "Response to Arguments" section, mischaracterizes this argument 
when stating that "Applicant further argues that cited references do not teach clearing routes 
from the table when a limit is reached." In this way, the Examiner, in the "Response to 
Arguments" section fails to address the deficiency of Sankaran, instead focusing on an argument 
the Applicant never made. The Examiner again appears to focus on a generalization of this 
feature of claim 11, and rejecting a generalized feature rather than consider the explicit claim 
language as a whole, which is required. Again, Applicant respectfully requests that the 
Examiner address the actual language, and not some generalized form of this language, that sets 
out this feature of claim 1 1 . 

Pesce in view of Sankaran and Gaddis fail to disclose or suggest these features defined by 
Applicant's claim 11, and provide no teaching that would have suggested the desirability of 
modification to arrive at the claimed features for the reasons presented in the previously filed 
Amendment and represented below for the Examiner's convenience. 

Failure to achieve the claimed invention and improper hindsight 
In addition, Applicant submits that the applied references, even if combined, result in a 
router that still suffers from the very deficiencies of the prior art implied by Applicant's 
specification. Paragraph [0038], for example, describes how routers or other network devices 
that do not support the techniques will not enter an "overload condition" in which a router 
intelligently removes itself from the network and effectively may avoids network failure through 
the update and successive advertisement of the updated routing information for the interior 
routing protocol. This feature is set forth, for example, in claim 1 1 as requiring, when the 
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number of routes exported from the exterior routing protocol process to the interior routing 
protocol process exceeds an export limit, operating the network device in an overload condition 
in which the network device: (i) updates routing information of the interior routing protocol to 
clear the routes previously exported from the exterior routing protocol, (ii) rebuilds the routing 
information of the interior routing protocol by updating the routing information of the interior 
routing protocol to associate interior routes with a maximum metric that defines a maximum 
distance from the network device to neighboring network devices, and (iii) advertises the 
updated routing information to another network device 

Applicant described potential befits of the claimed techniques on pages 9 and 10 of the 
previously filed Amendment as follows: 

To aid the understanding of how advertising this information may 
effectively remove the network device from the network, consider that other 
network devices that receive this routing information typically respond by 
performing a process referred to as routing [sic] resolution to select routes to 
interior network destinations based on the advertised metrics. By advertising 
metrics associated with a maximum value (i.e., a value sufficient to cause the 
other network device to select routes other than those routes advertised by the 
overloaded network device) the other network devices select alternate routes to 
the same destinations that avoid the network device) "effectively" removes the 
overloaded network device because the other network devices will most likely 
select the other route. If there is not another route to the same destination, 
however, the other network devices will select the overloaded network device but 
will do so knowing that it may take longer to reach that destination than it 
normally would. Consequently, should an overload condition occur, the 
techniques set forth by claim 1 1 provide a form of graceful failure that allows the 
overloaded router to provide limited routing functionality for routes that require 
use of the router. 

In other words, interior routing protocols may be overloaded causing network devices, such as 
routers, to fail or choke when processing routes leaked from an exterior routing protocol to the 
interior routing protocol. Pesce does not recognize this problem or provide a solution. In fact, 
Pesce appears to overlook this aspect of the prior art. Sankaran does not recognize this 



6 



Application Number 10/687,989 

Response to Office Action mailed July 9, 2010 

deficiency, but instead focuses on limitations of the hardware, i.e., space available to store routes 
on storage devices and memory, within the network device, which is a distinctly different 
problem from that solved by the techniques set forth by claim 1 1 . Gaddis, like Pesce, does not 
address this problem or provide a solution to this problem. 

The Examiner relies on this combination of Pesce in view of Sankaran and Gaddis to 
form the rejection of claim 1 1 without one of these applied references so much as mentioning 
this problem nor providing any solution to the problem. As such, the combination set forth by 
the Examiner appears to arise out of improper use of hindsight. Absent access to Applicant's 
disclosure, one of ordinary skill in the art would have found no reason to combine the cited 
references in the manner proposed by the Office Action to result in the features of amended 
claim 1 . The United States Supreme Court recently reiterated its counsel to other courts as well 
as the U.S. Patent Office, stating "A factfinder should be aware, of course, of the distortion 
caused by hindsight bias and be cautious of arguments reliant upon ex post reasoning." 1 
Modification of Pesce in view of Sankaran results in a system capable of defining a threshold 
and a threshold-specific discard algorithm that limits the exportation of routes from the exterior 
routing protocol to the interior routing protocol based on a storage capacity available to store 
routes by the interior routing protocol, which is substantially different from the techniques set 
forth in claim 1 1 for the reasons both noted above and below. Further combining Gaddis with 
this Pesce/Sankaran system results in a system that enables the definition of this threshold as a 
size limit placed on the prefix/mask. Applicant is unsure as to how this combination may 
produce any feasible result, let along the results that may be achieved by the techniques set forth 
by claim 1 1 . 

Remarks 

The remainder of the current Final Office Action reiterates the rejection presented in the 
previous Non-Final Office Action mailed January 6, 2010 with some minor updates or changes. 
In response to this reiterated rejection, Applicant reproduces below for the Examiner's 
convenience the arguments previously presented in the prior Amendment filed May 6, 2010, 
updating these arguments where appropriate to correct for typographical errors and the current 
status of the claims. 

1 KSR Int'l Co. v. Teleflex, Inc., 550 U.S. 398, 421 (2007). 
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Pesce, Sankaran and Gaddis 

With reference to independent claim 11, Pesce, Sankaran and Gaddis lack any teaching 
that would have suggested a method comprising, when the number of routes exported from the 
exterior routing protocol process to the interior routing protocol process exceeds an export limit, 
operating the network device in an overload condition in which the network device: (i) updates 
routing information of the interior routing protocol to clear the routes previously exported from 
the exterior routing protocol, (ii) rebuilds the routing information of the interior routing protocol 
by updating the routing information of the interior routing protocol to associate interior routes 
with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices, and (iii) advertises the updated routing information to another 
network device. 

The combination of references fails to provide any teaching to suggest these aspects of 
Applicant's claim 1 1 . Pesce teaches to a system that allows routing information stored to a first 
routing database to be exported to a second routing database in accordance with stored route 
mapping information. 2 Pesce describes one example of applying this route mapping information 
in column 3, lines 23-28 in which the stored route mapping information is used to export "said 
routing information from a first routing database ... of the first routing source, e.g., the OSPF 
protocol, and [import] it into a second routing database ... of a second routing source, e.g.., the 
BGP protocol." The OSPF protocol is often considered an interior routing protocol, while BGP 
is often considered an exterior routing protocol. Pesce further indicates that this system may 
employ blocking information that "identifies at least one couple of routing sources . . . and 
overrides the routing mapping information." 3 Pesce explains that this blocking information is 
useful "in order to leave to the operator the possibility of blocking some kind of mapping in 
particular operating conditions of the network." 4 Pesce suggests that each rule in a table that 
stores the route mapping information, where such rule is referred to an entry in a set rule table, 
comprises information relating to at least a metric value and a metric scale. 5 Pesce, however, 
provides little clarification as to what this metric represents. In column 9, lines 17-25, Pesce 



2 Abstract. 

3 Column 4, lines 52-59. 

4 Column 4, lines 59-61. 

5 Column 5, lines 15-18. 
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indicates that a lower metric value is to be used for a metric filter, where "[i]n order to match, 
routes must have a metric value higher or equal to the value reported in this field." 

In rejecting the aspect of claim 1 1 directed to rebuilding the routing information of the 
interior routing protocol by updating the routing information of the interior routing protocol to 
associate interior routes with a maximum metric that defines a maximum distance from the 
network device to neighboring network devices, the Examiner suggests that the metric associated 
with the rules of the route mapping information is the same as Applicant's maximum metric that 
is associated with the routing information of the interior routing protocol, which is clearly 
improper. Pesce explicitly teaches that this metric value is associated with the route mapping 
information, not the routing information. Moreover, Pesce does not actually describe updating 
this metric, which is substantially different from the Applicant's claim 1 1 that specifically 
requires rebuilding the routing information of the interior routing protocol by updating the 
routing information of the interior routing protocol to associate interior routes with a maximum 
metric that defines a maximum distance from the network device to neighboring network 
devices. 

Moreover, Pesce provides for blocking information that blocks the exportation of certain 
routes during the exportation process. This blocking information however does not update 
routing information of the interior routing protocol to clear the routes previously exported from 
the exterior routing protocol, as required by claim 1 1 . That is, Pesce provides a mechanism to 
prevent the exportation of certain routes but this blocking information does not clears routes 
previously exported. Consequently, Pesce does not teach or suggest update routing information 
of the interior routing protocol to clear the routes previously exported from the exterior routing 
protocol, as required by claim 1 1 . 

Neither Sankaran nor Gaddis teach or suggest these aspects of Applicant's claim 1 1 and 
thereby cure the deficiencies noted above with respect to Pesce. Consequently, the combination 
of references lack any teaching to suggest rebuilding the routing information of the interior 
routing protocol by updating the routing information of the interior routing protocol to associate 
interior routes with a maximum metric that defines a maximum distance from the network device 
to neighboring network devices and updating routing information of the interior routing protocol 
to clear the routes previously exported from the exterior routing protocol, as required by 
Applicant's claim 11. 
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In rejecting Applicant's claim 11, the Examiner only relies on paragraphs [0035] and 
[0045] of Sankaran for its teaching regarding what the Examiner characterizes as maintaining a 
count of routes exported and rejecting additional routes exported when the count exceeds the 
export limit set by the command. Paragraph [0035] of Sankaran discloses a threshold that 
triggers different discard algorithms. In this sense, paragraph [0035] of Sankaran provides for 
"threshold-specific discard algorithms" that are applied once certain storage thresholds are 
reached. Consider the example set forth in this portion of Sankaran, which provides that "once a 
threshold (e.g., a first threshold) is reached, a threshold-specific algorithm is applied . . . [and] 
once another threshold (e.g., a second threshold) is reached, another threshold-specific discard 
algorithm is applied." According to this portion of Sankaran, the thresholds are defined in terms 
of a percentage of a storage capacity available to store routing information and the threshold- 
specific discard algorithms apparently remove redundant routes from the route table. Paragraph 
[0045 of Sankaran reiterates various teachings of paragraph [0035] in operation with respect to a 
particular example. 

Yet, these cited portions of Sankaran do not teach or suggest rebuilding the routing 
information of the interior routing protocol by updating the routing information of the interior 
routing protocol to associate interior routes with a maximum metric that defines a maximum 
distance from the network device to neighboring network devices, as required by Applicant's 
claim 1 1 . In this respect, Sankaran does not cure the deficiencies of Pesce noted above. 

In addition, the portions of Sankaran relied on by the Examiner to reject claim 1 1 fail to 
even so much as suggest other aspects of claim 1 1 . For example, the portions of Sankaran relied 
on by the Examiner refer to thresholds defined in terms of a percentage of a storage capacity, 
which is substantially different from an export limit that limits the number of routes exported 
from the exterior routing protocol process to the interior routing protocol process in the manner 
required by Applicant's claim 1 1 . 

As another example, Sankaran culls the routing table to remove redundant routes (i.e., 
duplicate routes) as noted by paragraph [0035], which is substantially different from updates 
routing information of the interior routing protocol to clear the all of the routes that were 
previously exported from the exterior routing protocol such that only interior routes remain, as 
required by Applicant's claim 1 1 . That is, the threshold-specific discard algorithm of Sankaran 
makes no distinction between routes previously exported from the exterior routing protocol and 
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interior routes learned via the interior routing protocol when culling routes in contradiction to the 
explicit requirements of Applicant's currently amended claim 11. 

Likewise, Gaddis does not cure the deficiencies of Pesce or Sankaran noted above. 
Gaddis is silent with respect to rebuilding the routing information of the interior routing protocol 
by updating the routing information of the interior routing protocol to associate interior routes 
with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices, as required by Applicant's claim 1 1 . In fact, Gaddis as noted 
below defines a prefix size limit to exclude routes from being injected, but fails to mention any 
process whereby routing information of an interior routing protocol is rebuilt after the routes 
have already been injected. Moreover, Gaddis does not teach or suggest an export limit that 
limits the number of routes exported from the exterior routing protocol process to the interior 
routing protocol process in the manner required by Applicant's claim 1 1 . 

According to the Examiner, neither Pescc nor Sankaran teaches a user-defined size 
threshold, but column 17, lines 29-34 of Gaddis teach what the Examiner characterizes as a 
prefix limit that may be set for injected routes. According to the cited portion of Gaddis, what 
the Examiner characterizes as a "prefix limit" is in fact a size limit that "may be placed on the 
prefix/mask to limit the volume of injected routes that will be used." The prefix/mask discussed 
in this portion of Gaddis refers to an address prefix or IP address mask and the size limit 
discussed in this portion of Gaddis refers to a limit on the size of the prefix/mask. Defining a 
limit on a prefix/mask is substantially different than defining an export limit that causes the 
network device to enter an overload condition in the manner required by Applicant's claim 11. 
Consequently, Gaddis does not cure this deficiency of Sankaran noted above. 

In summary, Pesce teaches to exporting routes between route tables maintained by 
different routing protocols, one of which may represent an exterior routing protocol while 
another represents an interior routing protocol. The Pesce system describes route mapping 
information to effect the exportation of routing information from the exterior routing protocol to 
the interior routing protocol. The route mapping information includes rules that are stored as 
entries to a set rule table, each of which may be associated with a metric value and a metric 
scope. Sankaran describes a system that provides for storage capacity thresholds, which when 
reached trigger a corresponding one of a plurality of different threshold-specific discard 
algorithms. The threshold- specific discard algorithms cull redundant routes regardless of 
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whether such routes represent routes exported from the exterior routing protocol to the interior 
routing protocol. Gaddis then provides teachings for a defining a size limit that limits the size of 
a prefix/mask. 

The combination of Pesce and Sankaran results in a system capable of defining a 
threshold and a threshold-specific discard algorithm that limits the exportation of routes from the 
exterior routing protocol to the interior routing protocol based on a storage capacity available to 
store routes by the interior routing protocol. Further combining Gaddis with this Pesce/Sankaran 
system results in a system that enables the definition of this threshold as a size limit placed on 
the prefix/mask. Applicant is unsure as to how this combination may produce any feasible 
result. Consequently, Applicant presumes that the Examiner cites Gaddis only for its suggestion 
that such thresholds may be user defined. 

Even with this assumption in mind, the Pesce/Sankaran/Gaddis system only enables 
thresholds to be defined that invoke a threshold-specific discard algorithm that culls routes 
regardless of whether these routes constitute exported routes or not. That Pesce enables metrics 
to be associated with the route mapping information and that routes can be blocked using 
blocking information seems irrelevant considering that the metric required by Applicant's claim 
1 1 is defined for actual routing information, not route mapping information, and the update of 
the routing information once the network device enters the overload condition is to clear routes 
previously exported, as noted above with respect to Applicant's claim 1 1, not block the 
exportation of routes. 

In this respect, the combination of Pesce, Sankaran and Gaddis fails to teach or suggest 
the method of Applicant's claim 1 1 comprising, when the number of routes exported from the 
exterior routing protocol process to the interior routing protocol process exceeds an export limit, 
operating the network device in an overload condition in which the network device: (i) updates 
routing information of the interior routing protocol to clear the routes previously exported from 
the exterior routing protocol, (ii) rebuilds the routing information of the interior routing protocol 
by updating the routing information of the interior routing protocol to associate interior routes 
with a maximum metric that defines a maximum distance from the network device to 
neighboring network devices, and (iii) advertises the updated routing information to another 
network device. 
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Independent claims 1, 8, 18, 27 and 33 

With regard to independent claims 1,8, 18, 27 and 33, the applied references fail to teach 
or suggest each and every limitation recited by these independent claims for at least one of the 
reasons noted above with respect to claim 1 1 . For example, Pesce, Sankaran and Gaddis fail to 
teach or suggest updating routing information to associate the routes with a maximum metric that 
defines a maximum distance from the network device to neighboring network devices when the 
count exceeds the export limit, as required by applicant's claim 1 . As noted above, none of these 
references teaches or suggests a maximum metric that defines a maximum distance from the 
network device to neighboring network devices. Pesce 's reference to a metric value and scope, 
again as noted above, falls short of the metric required by claim 1 in that the Pesce metric value 
refers to a metric associated with route mapping information not actual routing information. 
Sankaran and Geddis do not cure this deficiency of Pesce. Consequently, the applied references 
to not teach this aspect of claim 1 . 

As another example, the applied Pesce, Sankaran and Gaddis references fails to teach or 
suggest maintaining respective counts of routes exported from an exterior routing protocol 
executing on the network device to each of the instances of the interior routing protocol 
executing on the network device, as required by currently amended claim 8. Instead, Sankaran 
only teaches to a storage capacity threshold, which is substantially different from maintaining 
respective counts of routes exported form an exterior routing protocol, as required by claim 8, as 
amended. To illustrate the difference, consider that Sankaran thresholds would not discriminate 
between exported routes and routes learned using the internal routing protocol as both would add 
routes that increase the amount of memory or storage consumed. In comparison, Applicant's 
currently amended claim 8 requires maintaining counts of routes exported from an exterior 
routing protocol, which is substantially different from the thresholds described by Sankaran. 
Consequently, the applied references to not teach this aspect of claim 8, as amended. 

To the extent independent claims 18, 27 and 33 recite limitations similar to those 
referenced above with respect to claims 1, 8 and 1 1, the arguments made above apply to these 
independent claims 27 and 33 and to the claims that depend from claims 1,8, 11, 18, 27 and 33. 

In the current Final Office Action, the Examiner rejected claims 6 and 32 under 35 
U.S.C. 103(a) as being unpatentable over Pesce et al. (U.S. Patent No. 7,328,278), Sankaran et 
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al. (U.S. Patent Publication No. 2003/0231587) and Gaddis et al. (U.S. Patent No. 7,554,930) in 
further view of Rochberger et al. (U.S. Patent No. 6,212,188). Applicant respectfully traverses 
the rejection 

Rochberger 

With respect to the additionally cited reference, Rochberger, the Examiner appears to 
only rely on Rochberger in rejecting claims 6 and 32 to teach or suggest setting an overload bit 
upon a network device entering an overload status. The portions relied on by the Examiner in 
rejecting these claims however fail to cure the deficiencies noted above with respect to the 
combination of Pesce, Sankaran and Gaddis. The combination of Pesce, Sankaran and Gaddis 
therefore fails to teach or suggest the techniques defined by Applicant's claims. 

For at least these reasons, the Examiner has failed to establish a prima facie case for non- 
patentability of Applicant's claims 1, 6, 8, 1 1-13, 15, 18-22, 26, 27, 30, 32, 33, 39 and 40 under 
35 U.S.C. 103(a). Withdrawal of this rejection is requested. 

CONCLUSION 

All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 

Date: September 9, 2010 By: /Matthew K. Gage/ 

Name: Matthew K. Gage, Reg. No.: 63,059 

SHUMAKER & SIEFFERT, PA. 
1625 Radio Drive, Suite 300 
Woodbury, Minnesota 55125 
Telephone: 651.286.8367 
Facsimile: 651.735.1102 
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